Alternately, we could depend on symfony/polyfill-iconv and/or symfony/polyfill-mbstring, allowing us to use the relevant iconv and/or mbstring functions directly in the code. On systems that have the extension(s) installed, these are ignored, but otherwise, we'd still be able to rely on them, without needing to write our own wrappers.

As I see it, a strategic decision is needed here, because problems with multi-byte strings will occur over and over again in a wide variety of components.

Possible options:

1. Develop further your own string wrappers in the package https://github.com/laminas/laminas-stdlib without using third-party components.
2. Develop further your own string wrappers in the package https://github.com/laminas/laminas-stdlib using Symfony components (under the hood).
3. Declare your own string wrappers as deprecated components and switch from them to using Symfony components directly.

@rugabarbo perhaps you assumed the polyfills that @weierophinney mentioned are Symfony components, they are not, they are absolutely framework agnostic, they are just composer packages under Symfony namespace:

• https://github.com/symfony/polyfill#symfony-polyfill

but if you meant really components, you mean string component? then it would require to use Symfony 5.0 which in turn requires PHP 7.2:

• https://symfony.com/blog/new-in-symfony-5-0-string-component
• https://github.com/symfony/string
• https://github.com/symfony/string/blob/v5.0.0/composer.json#L19

but this project is yet at PHP 7.1:

• https://github.com/laminas/laminas-validator/blob/2.13.4/composer.json#L32

I personally would just go using polyfills, which can be replaced with real extensions using composer "replace" key:

• https://github.com/eventum/eventum/blob/v3.9.3/composer.json#L96-L99

I've pushed changes that demonstrate an attempt at fixing this using symfony/polyfill-mbstring. I installed that package, and then updated all string-related functions that have mbstring equivalents to the mbstring versions. When I was done, I noted the following:

• Your first new test case passed.
• The second new test case failed.
• The lower-case version of the second case, which already existed, also failed.

Out of curiousity, I tried the same experiment using symfony/polyfill-iconv. However, in that scenario, the tests you've created continued to fail entirely.

I'm not quite sure where to go with this at this point, but I've left my symfony/polfill-mbstring experiment in here for you to work with. You'll need to fetch and rebase your branch.

I've rebased this off current 2.14.x sources so that it can pick up our new CI. However, the tests as presented are still failing and it looks like it's likely due to the letter casing. I attempted to change the regexp to add the u flag, but that made no difference, so I did not push that change here.

At this point, I need somebody with experience in i18n casing issues to assist.